System and Method for Facilitating On-Line Payment

ABSTRACT

The present invention relates to a system and method for facilitating on-line payment particularly for goods or services purchased via a merchant site on the Internet. The system enables payment from an existing customer account at a financial institution, but does not require the user to provide credit card details. The payment is implemented in real-time from the customer account to a merchant account via a financial institution application such as an Internet banking website. An interface is provided which is initiated via the merchant site and which then interfaces the customer computer to the financial application having access to the customer computer&#39;s account. The customer can then enter payment details directly with the financial institution to pay the merchant directly for the transaction.

RELATED APPLICATIONS

This application claims the priority of, and hereby incorporates byreference, non-provisional application Ser. No. 10/561,699 filed May 15,2006; which is a U.S. National Phase of International Patent ApplicationSerial No. PCT/AU2004/000846, filed Jun. 25, 2004, which claims priorityto Australian Patent Application No. 2003903229, filed Jun. 25, 2003.

FIELD OF THE INVENTION

The present invention relates to a system and method for facilitatingon-line payment and particularly, but not exclusively, to a system andmethod for facilitating on-line payment for goods and/or servicespurchased via a network based merchant site.

BACKGROUND OF THE INVENTION

One of the major barriers to user uptake of on-line shopping is the lackof or at least perceived lack of security in relation to the provisionof payment details, such as credit card numbers, to merchant sites.There is such a reluctance to provide credit card or debit card detailsto merchants that surveys carried out in relation to on-line shoppinghave determined that anywhere between 25% and 75% of customers abandontheir “shopping carts” without completing purchase.

There are other reasons for non-completion of purchase apart fromcustomers not trusting merchant sites with their credit card details.These include the fact that not all on-line consumers have credit cards,and, for those with credit cards, credit limits may have been reached.

Customer initiated direct debit is known for on-line payment of bills,such as utility bills, and for recurring payments, but the sites needprior standing authority from the user, usually organised throughoff-line mechanisms. Without this explicit authority no third parties,such as merchants, are able to access funds from the customer. Such anarrangement is tedious and inconvenient to set up. In any event,customers are extremely reluctant to give authority to a third party toaccess their funds and there are concerns about fraud and difficulty incancelling such an authority.

Presently, there is no mechanism for enabling direct payment from acustomer's usual account, such as a bank account, to a merchant'saccount, during an on-line product transaction initiated from amerchant's site.

These difficulties give rise to a low rate of uptake of on-linemerchandising.

SUMMARY OF THE INVENTION

In accordance with a first aspect, the present invention provides asystem for facilitating on-line payment for an on-line producttransaction, comprising an interface means which is arranged to beinitiated via a merchant site and is arranged to provide a connection toa financial institution application to enable processing of the payment,via the financial institution application, to a merchant account.

By “on-line payment” is meant any payment which is initiated over anetwork connection. By “on-line product transaction” is meant anytransaction for a product which occurs over a network connection. Anetwork may be any computing system or telephony network. “Computingsystem network” includes any network of computing devices. “Computingdevices” include conventional computers, PCs, laptops, and mobilecommunications devices such as mobile telephones, personal digitalassistants, and any computing system which is connectable to a network.

A “product transaction” is a transaction for any product, which mayinclude goods and/or services.

A “merchant site” is a computer network site provided by a computingsystem which is connectable to the network to offer products for salevia the network to customers. A “financial institution application” mayinclude any application operated by a financial institution, such as abank or other account providing authority. The financial institutionapplication will be usually provided by a financial institutioncomputing system which is connectable to the network to make availablethe financial institution application.

A typical computer network on which on-line product transactions takeplace is the Internet. The Internet offers many merchant sites which canbe browsed by customers to enable customers to determine whether theywish to purchase a product. The present invention is not, however,limited to application on the Internet only. It may be applied to anycomputer network where products are sold on-line and with the facilityto connect to financial institution systems.

Preferably, the interface means enables the payment to proceed in “realtime”. This preferably enables payment to occur during the producttransaction.

Payment may be by way of any stored valued methodology eg. money,loyalty points, etc.

Preferably, the interface means is arranged to be initiated via themerchant site via a customer operating a customer computing system.

Preferably, the interface means is arranged to generate confirmation toa merchant system that payment has occurred. Preferably, theconfirmation enables the merchant system to complete the producttransaction. Preferably, the system is arranged to establish aconnection with the financial institution computing system forgeneration of confirmation that payment has occurred. Preferably theconnection is established between the merchant site and the financialinstitution computing system. Preferably the connection is a secureconnection. This advantageously avoids fraudulent generation ofconfirmation of payment, therefore reducing the chances of fraud andassuring the merchant that the confirmation is generated by thefinancial institution computing system.

Preferably, the interface means is arranged to obtain details of thetransaction and provide those details to the financial institutionapplication to enable payment. Preferably, the transaction detailsinclude the amount of payment. Preferably, the transaction detailsinclude information which may be required to identify the transaction.For example, the transaction details may include a merchant accountidentifier.

In one embodiment, the interface means is arranged to interface withknown pre-existing financial institution applications. These includefinancial institution applications provided by so-called “Internetbanking” sites.

Financial institution applications usually require a security means tobe entered to enable operation to carry out processes such as payment bya customer (who may hold an account with the financial institution) tothird party accounts. In one preferred embodiment, the interface meansinterfaces a customer's computing system to the financial institutionapplication to enable the customer, who is facilitating the transactionat the merchant site, to enter their security means (which may be apassword, PIN or any other type of security means).

In an alternative embodiment, the system for facilitating on-linepayment includes an agent application which is arranged to automaticallyenter the security means to the institution application. The agentapplication is preferably arranged to obtain the security means from acustomer computing system, the security means being stored in a storagelocation accessible by way of the customer computing system. Preferably,the security means is stored in encrypted form. The agent application ispreferably arranged to obtain the decryption key for the customer'sencrypted security means, to enable decryption of the security means.The agent application may operate in a similar manner to that of theactive content agents described in the applicant's pending internationalpatent application, no. PCT/AU02/00150, filed on 14 Feb. 2002.Disclosure of this document is incorporated herein by reference.

The system is preferably arranged to store a record of transactiondetails for a transaction.

The system preferably further includes a database arranged to storetransaction details of transactions. This database may be accessible bymerchants and/or customers in order to enable them to monitor thehistory of transactions they have carried out via the system.

Preferably, the system of the present invention may be used tofacilitate payment for a transaction from a debit or credit account of acustomer to a designated account of a merchant.

In at least a preferred embodiment, the system of the present inventionprovides the advantages that a customer accessing a merchant site andwishing to purchase a product, can make payment for that product in“real time”. In the preferred embodiment, the interface means connectsthe customer system to a designated financial institution applicationwhich enables the customer (under control of the interface means) tomake payment from customer account (e.g. a standard cheque accountavailable on-line) to a designated merchant account. The system thenconfirms to the merchant that payment has been made so that transactioncan proceed (e.g. delivery of the product can be authorised). In oneembodiment, as discussed above, a secure connection is made between themerchant site and the financial institution computing system forconfirmation that payment has been made to the merchant.

In at least the preferred embodiment, the transaction payment is carriedout under the control of the customer who is paying. The customer doesnot have to give any security means (such as credit card information,account identification information, etc.) to any other third party,other than the financial institution that they usually deal with (by wayof the financial institution application). No passwords or credit cardnumbers need to be given to merchants that the user may not trust. Themerchant, in turn, has the comfort of being aware that payment hasoccurred before he delivers his product.

In accordance with a second aspect, the present invention provides amethod for facilitating on-line payment for a transaction between acustomer and a merchant, comprising the steps of, during a transactionvia an on-line merchant site, accessing a financial application andmaking the financial application available to enable a payment from acustomer's account to an account of the merchant.

Preferably, the method comprises the further step of operating thefinancial application to make the payment.

In accordance with a third aspect, the present invention furtherprovides a computer program arranged to control a computing system toimplement a system in accordance with the first aspect of the presentinvention.

In accordance with a fourth aspect, the present invention provides acomputer readable medium providing a computer program in accordance withthe third aspect of the present invention.

In accordance with a fifth aspect, the present invention provides asystem for facilitating on-line payment for a product transaction,comprising an interface means which is arranged to be initiated via amerchant site and is arranged to provide connection to a payment meansto enable processing of the payment to a merchant account.

Preferably, the interface means is arranged to connect a customercomputer accessing the merchant site to the payment means whereby thecustomer computer can initiate payment.

Preferably, the payment means is provided by a financial institutionsite.

A further aspect of the present invention may relate to on-line paymentof transaction such as bills, and peer to peer payment.

In accordance with a sixth aspect, the present invention provides asystem for facilitating on-line payment, the system comprising aninterface means which is arranged to be initiated via a system messageand is arranged to provide connection to a payment means to enableprocessing of the payment.

A system message may be any message which can be transmitted via anetwork. Preferably, the system message is an e-mail message.

In a preferred embodiment, therefore, one party may send an e-mailmessage to another party, the e-mail message indicating to the otherparty a requirement for payment. For example, the e-mail message mayinclude a bill for utility service. The e-mail preferably includes alink which is enabled to connect the further party to a payment means,such as through a merchant site, to enable payment in response to themessage.

In accordance with a seventh aspect, the present invention provides amethod for facilitating on-line payment, comprising the steps of using asystem message initiating payment for a transaction, to link atransaction payers computing device to a payment means to enableprocessing of the payment.

In accordance with an eighth aspect, the present invention provides acomputer program including instructions for controlling a computingsystem to implement a system in accordance with the sixth aspect of thepresent invention.

In accordance with a ninth aspect, the present invention provides acomputer readable medium providing a program in accordance with theeighth aspect of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the present invention will become apparentfrom the following description of an embodiment thereof, by way ofexample only, with reference to the accompanying drawings, in which;

FIG. 1 is a schematic diagram for illustrating operation of a system inaccordance with an embodiment of the present invention;

FIGS. 2 through 7 are example computer screen displays for illustratingoperation of an embodiment of the present invention;

FIG. 8 is a an example computer screen display illustrating transactiondata records which may be produced in accordance with an embodiment ofthe present invention; and

FIG. 9 is a flow diagram illustrating a process in accordance with anembodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

A system and method in accordance with one embodiment of the inventionwill now be described with reference to the accompanying drawings.

The system and method of this embodiment of the invention facilitateon-line transactions. By “on-line transactions” is meant any transactionwhich occurs over any network. The example network used in the followingdescription is the Internet. The invention may be applied in any networkenvironment, and is not limited to application over the Internet.

The system of this embodiment includes an interface means, which will beillustrated and described in detail later, and which in this example isimplemented by an appropriate server computing system 1 which isconnected to the Internet 2 via appropriate communication means 3. Theinterface means in this example includes software which is arranged tobe made available over the network by the server computer 1.

Also illustrated in FIG. 1 is a merchant computing system 4. Themerchant computing system 4 may include any appropriate type of servercomputing system 4 which is arranged to serve Web pages 5 on theInternet 2, in order to provide a merchant site where, for example,products may be offered for sale. In the illustration a single merchantsystem 4 is shown. This merely serves as an illustrative example of manyexisting merchant computing systems arranged for connection to theInternet 2. The present invention may be implemented via any suitablemerchant system, and is likely to be implemented on many merchantsystems. The merchant system 4 is arranged to serve web pages 5, toprovide a website via which information on products (including goodsand/or services) may be accessed and via which products may be purchasedin a known manner. In accordance with this embodiment of the invention,the merchant computing system 4 is also arranged to operate with theinterface means provided by the system 1.

Also shown in FIG. 1, are customer computing systems 6. The customercomputing systems 6 may comprise any appropriate computing systemincluding appropriate software and hardware and in this examplaryembodiment are illustrated as being PCs including a computer 7, monitor8, keyboard 9 and mouse 10.

The user computing systems 6 includes browser or other software 11 whichis arranged to enable the computing system 6 to browse or access Webpages over the Internet 2, such as Web pages 5 provided by the merchantsystem 4. Browsers are known.

In FIG. 1, three user computing systems 6 are shown. This is forillustrative purposes only. As is well known, there are many customercomputing systems which are arranged for connection to networks such asthe Internet, so that, for example, customers can browse variousmerchant sites (as well as other Web pages) in order to select productsfor purchase. This embodiment of the present invention may beimplemented for many customer computing systems and many customers.

Conventionally, when a customer accesses the Internet to view a merchantsite, their browser brings up the appropriate Web page and the userstudies the Web page(s) and selects an appropriate product (by way of a“shopping basket”) for purchase. In order to proceed with the purchase,the customer must then provide payment details to the merchant site.This is most usually done by way of providing credit card details. Asdiscussed above, many people are reluctant to provide their credit carddetails to merchant sites.

The majority of customers keep accounts with financial institutions,such as banks. The majority of financial institutions offer serviceswhich are available on-line. These services may include access to acustomer's account records. They may also include facilities whichenable a customer to pay third parties directly from their account. Forexample, the financial institution may offer an on-line financialapplication which enables a customer to pay from their account to athird party whose account details, or some account identification of thethird party, are provided to the application. The third party's accountdetails or identification may include account number, which financialinstitution the third party holds the account with, and other requireddetails.

In FIG. 1, a server computing system 12 of the financial institution isillustrated. The financial institution server computing system 12 isarranged to serve Web pages 13 to the Internet 2. Web pages 13 mayenable operation of the financial applications for allowing access tocustomer account records and making account transfers, and otherfunctions. Such applications are known.

Only a single financial institution server computer 12 is illustrated inthe drawings. It will be appreciated that there may be many financialinstitutions arranged to serve Web pages for facilitating financialapplications. The present invention may find use with many suchfinancial institution applications, and the single server computer 12 isshown for illustrative purposes only.

The system of this embodiment of the present invention includes aninterface means, which in this embodiment is in the form of a softwareapplication provided by server computing system 1. The interface meansoperates to connect to the financial institution application provided bythe financial server computer 12, to enable payment to an account of amerchant associated with the merchant system.

In this embodiment, the system 1 of the present invention also includesa transaction record database 15 for storing records of transactionsoccurring via the system 1 and also a decryption key database 16 whichstores decryption keys for decrypting encrypted customer security meansand which will be described in more detail later. The system 1 of thepresent invention may be implemented by any appropriate computinghardware and software. Although databases 15 and 16 are shownseparately, they may be implemented by combined hardware/software.

The customer computing system 6 also may include software in the form ofa digital safe 17 and an “active content agent” engine 18. The functionof these will be described in more detail later.

Operation of an embodiment of the present invention will now bedescribed by way of illustrative example with reference to the examplecomputer screen displays of FIGS. 4 through 7. The example screendisplays have MICROSOFT® toolbar layouts and “look and feel”. Thepresent invention is not limited to this format any appropriate formatmay be used. Please note that where brand names and trade marks areshown in the drawings, they are for example purposes only and are in noway limiting to the invention.

The example computer screen display shown in FIGS. 2 through 7 are thedisplays which will appear on a customer system 6 monitor 8.

With reference to the Figures, the customer computer 6 accesses amerchant site provided by Web pages 5 supported by merchant computingsystem 4. In this illustration, the merchant site offers for saledigital video discs (DVDs). The customer browses the merchant site andmay select one or more DVDs for purchase. The customer then proceeds toa “payment” page on the merchant site, the payment page 20 beingillustrated in FIG. 2. The payment page displays the merchant brand name21 (in this case Price Buster DVD's (Pty) Ltd). The payment page 20 alsodirects 22 the customer to select a payment method. The payment methodsavailable on payment page include the conventional payment method ofpaying by credit card 23. It also includes the option 24 of paying themerchant by way of the payment system and method in accordance with anembodiment of the present invention. The payment method 24 is labelledwith the brand name “eWise Pay 3P” 25. This is a brand name only. Anybrand name or any other designation of a payment method may be utilised.A drop-down menu 26 is available for selecting a financial institutionapplication to facilitate payment to the merchant.

The page also includes a “Biller Code” 27, and “Amount” 28 and atransaction “Reference” 29. Some or all of this information may or maynot be shown on the page 20. For example, in an alternative embodiment,the Biller Code 27 may not be shown, and instead may be stored andretrieved from a database.

The amount 28 is the amount that the customer needs to pay to themerchant.

FIG. 3 is a further view of the payment page 20, showing details of thedrop-down menu 26. It is clear from this that there are a number offinancial institution applications (in this case four) available for thecustomer to select. Note that any number of financial applications maybe provided for selection. This will depend upon the number of financialinstitution applications that the present invention is authorised foruse with and also the number of the financial institution applicationswhich may be available.

The customer selects one of the financial institution applications 26for payment to the merchant (the customer will usually select afinancial institution application of a financial institution where theyhold an account). The selection initiates operation of the system 1 ofthe present invention. The system 1 provides a “payment gateway” display30 (FIG. 4). The payment gateway 30 opens in a separate browser windowon the user computer 6 (note that it may open in the same browserwindow). The page 30 is served by the system 1 in accordance with thepresent invention. Note that the payment gateway display 30 displaysbranding 31 of the financial institution deploying the system. Whetheror not this branding is displayed is optional.

Other information may also be displayed in the payment gateway 30 page.Shown in FIG. 4 is the “Merchant Name” 32, a “Reference” 33 and apayment amount 34. The “Amount Paid” information includes type ofpayment that would occur, in this particular example being a directdebit. Note that the further or alternative information may be includedin the payment gateway page 30 as desired.

In this embodiment, the system 1 utilises a software application in theform of a software agent in order to provide an interface to thefinancial institution application selected. Once the system 1 isinitiated by selection of the payment method 24 and selection of thefinancial institution application, the software agent navigates theInternet 2 to locate the financial institution system 12 and website 13served by the financial institution system. The software agent thenconnects the customer computer 6 to the website of the financialinstitution, so that the customer can connect to the financialinstitution application. In this embodiment, the agent application isalso arranged to extract payment details from the merchant system andprovide those payment details to the financial institution application.

When the agent application has navigated to the financial institutionsystem 12 the appropriate Web page 13 is served to the customer computersystem 6. FIG. 5 shows one example of an “Customer Sign In” page 35provided by one particular financial institution application. This pageincludes some information (the information will depend on the financialinstitution application being accessed) and also a “Customer Sign In”section 36 requiring entry of a security means to enable access to thefinancial institution application. It is to be noted that the financialinstitution application is a pre-existing application. The agentapplication of this embodiment of the present invention has interfacedthe customer computer 6 automatically to the pre-existing financialinstitution application without requiring any operation by the customerother than to select the financial institution application to benavigated to from the merchant site. Note that FIG. 5 gives one exampleonly of a financial institution application, and the present inventionmay be used with any financial institution application.

The next step in the process is that the customer enters their securitymeans to the Customer Sign In section. In this example the securitymeans includes a Customer Number 37 and a Password 38. The securitymeans may include any type of security means, depending upon thesecurity means required by the financial institution application.

Note that in an alternative embodiment to be described later, the systemof the present invention may automatically provide the security means tothe financial institution application. In the illustrated embodiment,however, the customer provides the security means themselves.

No security means is provided to the merchant site. The customer insteadprovides the security means directly to the financial institutionapplication. This is something that the customer is comfortable withdoing. There is no potential for the merchant, therefore, to illicitlyaccess the customer's account via the financial institution application.The payment to the merchant via the financial institution application isunder the control of the customer and is separated from the merchantsystem.

Once the security means have been entered, the financial institutionapplication operates to enable payment to the merchant. The agentapplication automatically navigates the site to the appropriate page.Referring to FIG. 6, the page 40 is served to the customer computer 6 bythe financial institution system 12. The page 40, in this example,enables entry of details for payment from an account the customer haswith the financial institution, to an account of the merchant (which maybe with the same financial institution or another financialinstitution). In this example, page 40 includes information such as theaccount “Pay From” 41, the “Payer Name” 42, a “Description” of what thepayment is for 43. The page 40 also includes information relating to themerchant payment details, including the “Account Name” 44 of themerchant, the current identification information including in thisexample a “BSB Number” 45 and an “Account Number” 46. It also includes a“Description” 47, which in this case is the Reference 33 which appearsin the merchant site as reference numeral 29 and on the payment gatewayas reference numeral 33 and which identifies the transaction to thesystem 1 of the present invention. The information also includes an“Amount” to be paid.

In this embodiment of the invention, as discussed above the agentapplication obtains payment details from the merchant site. It may alsoobtain details of the payer either from the merchant site or thecustomer computer or a system database. In the example shown, thedetails obtained by the agent application are automatically entered intothe financial institution application. These details include the PayerName 42, the Description of the item 43, the Account Name of themerchant 44, the BSB Number 45, the Account Number 46, the Description47 and the Amount 48. One advantage of having these detailsautomatically entered into the financial institution application is thatthey will be accurate without any potential for customer error.Conventionally, a customer would enter the details via a user terminal6, which can often result in error. The agent application is arranged toobtain the details that are relevant for the particular financialinstitution application. The agent application therefore operates byfirst detecting which financial institution is selected at the merchantsite and then obtaining the details that it knows are required for thatfinancial institution application from the merchant site and (ifrequired) the customer computing system 6.

Note that the account of the customer 41 may be selected by the customeror may automatically be selected by the agent application based oninformation provided by the customer computer.

Note that this page and other pages may not be visibly displayed to theuser in the case where it is fully automated by the agent.

Following submission of the payment details and processing by thefinancial institution application of the payment to the merchant, thesystem 1 of the present invention produces a “Payment Received” page 50(FIG. 7). This page is similar to the initial Payment Gateway page 30.It includes further details, however. In particular it includes a dateand time 51 on which payment was made. It confirms 52 the amount ofpayment that was made and the date. It provides information on thereceipt 53 which is provided by the system 1 to the merchant system 4.It also includes some further reference information 54 providing detailsof the account paid from and the financial institution receipt numberthat the agent extracted automatically from the financial institutionsite. The merchant therefore receives an official receipt of payment totheir account of the required funds for the transaction. They cantherefore organise delivery of the product to the customer in thecomforting knowledge that they have already been paid. In oneembodiment, the system implements a process to reduce or avoid thepotential for provision of a fraudulent receipt to the merchant. In thisembodiment, the customer system 6 transfers the relevant sessioninformation to the merchant server 4 before the financial institutionsystem 12 issues the receipt page 50. The merchant system 4 thenestablishes its own Secure Socket Layer (SSL) session either directlywith the financial institution system 12 or via the customer system 6,providing an end-to-end SSL session between the financial institutionsystem 12 and the merchant system 4. SSL communication is known. Thecustomer's existing session with the financial institution system 12 maybe maintained. Because the merchant system 4 has a direct SSL sessionwith the financial institution server 12, the merchant can be assuredthat the receipt information they are receiving is being provided by thefinancial institution not by a fraudulent process eg a fraudulentcustomer system.

The establishment of the additional/alternative communication channelbetween the merchant system 4 and the financial institution system 12does not require that the customer disclose any of their authenticationdetails to the merchant system 4.

In one embodiment, the payment confirmation details may be digitallysigned by the financial institution. Where the financial institutiondigitally signs the payment confirmation, the system 1 of the presentinvention validates the signature to ensure validity before notificationto the merchant.

Note that a “Return to Merchant” button 55 is provided for thecustomer's return to the merchant site.

FIG. 8 is an example computer display screen which may be viewed via amerchant system 4 and shows a records page 60 of transaction recordsstored in database 15 of the system 1. The system 1 serves the page 60to the merchant system 4 so that the merchant can view the transactionrecords of the transactions that have occurred via the system 1.

The records may be represented in any convenient form on the page 60. Inthis example, the records include information such as “Biller Code” 61;“Biller Name” 62; “Reference” 63; “Account Paid Via” 64; “Comment” 70;“Amount Paid” 66; “Date Paid” 67, and the “Receipt Number” 68.

Records may also be provided for access by a customer computer server sothat a customer can view transactions that they have paid via the system1.

In the above embodiment, the customer is expected to remember and entertheir own security means to enable access to the financial application(FIG. 5). In an alternative embodiment, the technology disclosed in theapplicant's co-pending international application no. PCT/AU02/00150 maybe employed to enable the agent application to automatically obtain thecustomer's security means and enter them to the financial institutionapplication.

Referring to FIG. 1, in this alternative embodiment a customer computersystem 6 includes software including a digital safe 17, and an ACA or“Active Content Agent” engine 18. The digital safe 17 stores inencrypted form (using any suitable encryption technology) the securitymeans of the user for enabling entry into the financial institutionapplication. Database 16 at invention system 1 stores decryption keysfor decrypting the encrypted security means in the digital safe 17.

In operation, the agent application which implements the interface tothe financial institution application, is also arranged to obtain thesecurity means 17 from the digital safe 17 of the customer computer 6.It does this by first determining the identity of the customer computer,then obtaining a decryption key from the database 16 which is arrangedto decrypt the encrypted code in the digital safe 17. As part of theregistration process, a customer would have their security means, suchas passwords, encrypted by the system 1 and be provided with a passwordto enable access of the agent application to the decryption key 16 forthe user computer 6 stored in the encryption key database 16. Thecustomer may be required to enter a password to the gateway so that theagent application can then automatically obtain the security means forthe financial institution application from the digital safe 17.

The ACA engine 18 determines whether the agent application is a correctagent application for the financial institution application and whetherit is authorised to access the customer computer 6 for digital safe 17.The agent application may be provided with a digital certificate whichthe ACA engine can use for authorisation. The ACA engine then executesthe agent application insofar as it enables the agent application toaccess digital safe 17 and decrypt the requisite security means for theparticular financial application. At the stage where the user isexpected to enter their security means to the financial institutionapplication (FIG. 5), this is automatically entered by the agentapplication. The rest of the process is then the same as with the aboveembodiment. Note that once the security means has been decrypted by theagent application, the decryption key is discarded and must be obtainedagain from the decryption database 16 for future operation.

FIG. 9 gives a summary flowchart of operation of the embodimentdescribed above. At step 70, a customer accesses a merchant site. Atstep 71, the system of the present invention is operated and the paymentgateway is called up onto the customer's computer. At step 72, thegateway implements operation of the agent application. At step 73, theagent application connects the user computer to the financialinstitution application that has been selected. At step 74, either theuser or the agent enter the security means and payment details to thefinancial institution application. At step 75, the institutionapplication processes payment. At step 76, the agent providesconfirmation of payment to the merchant site and stores a transactionrecord in a database. As discussed above, the confirmation of payment tothe merchant site may be made by secure connection between themerchant's system and the financial institution system.

The above description of the embodiment shows one particularimplementation of the present invention. The invention is not limited tothis particular implementation and may be implemented in a number ofdifferent ways. For example, the agent application describedautomatically fills in payment information to the financial institutionwebsite. This need not be the case. In an alternative embodiment theagent application merely connects the customer to the financialinstitution application and the customer fills in the details. The agentthen extracts the receipt and notifies the merchant of the completedpayment. One advantage of the present invention is that the interfacemeans can be adapted to interface with any pre-existing financialinstitution application. Advantage can therefore be taken of the factthat there are already many financial institution applications inexistence which enable a user to pay third parties. The presentinvention is not limited to use with pre-existing financial institutionapplications, however. Financial institution applications may, forexample, be designed specifically for use with the system and method ofthe present invention. The present invention may also, obviously, beused with financial institution applications that are designedsubsequent to implementation of the present invention.

The computer display pages illustrated in the drawings are described inrelation to the specification embodiment of one particular form. Theinvention is not limited to this form. Any appropriate form or formatmay be used with the present invention. Further, different informationto that information shown in the specific embodiment may be utilised andillustrated in pages used with the present invention.

In the above description of the preferred embodiment, it is assumed thecustomers utilising the invention will access the merchant sites fromtheir own computing system. The present invention is not limited tothis, however. There is potential for customers to access from anycomputing system which is connectable to the network.

In the above description of the preferred embodiment, the agentapplication and other components of the system are implemented byappropriate software supported by appropriate hardware. Anysoftware/hardware mix that can implement the invention falls within thescope of the present invention.

In the above described embodiment, the financial institution systemprovides a website accessible by way of the Internet. The presentinvention is not limited to use with financial institutions that provideaccess to their applications by way of Internet websites. Other methodsof connection from a network to the financial institution may beutilised with the present invention. For example, the system 1 of thepresent invention may in some cases have a direct connection to afinancial institution, the direct connection being implemented whenconnection to a financial institution application is required. Further,the network is not limited to the Internet. The present invention may beimplemented over any appropriate network.

Generally, the present invention provides interface means which isarranged to connect to a payment means so that the processing of paymentto a merchant account can be carried out. In this, in at least apreferred embodiment, is without requiring any security means to beprovided by the customer to the merchant.

In the above described embodiment, the customer account is a debitaccount. The present invention is not limited to use with a debitaccount. The account may be any type of account. For example, theaccount may be a credit card account, and the credit card details wouldbe provided to the financial institution application for credit to themerchant.

In a variation of this invention, on-line payment may be facilitatedwithout requiring that customer first access a merchant site. In thisvariation, peer to peer payments can be facilitated and bill paymentscan be facilitated. Implementation is similar to the implementationdiscussed above in relation to first embodiment of the presentinvention. Instead of initiation of the payment being by way of merchantsite, however, initiation is via a system message. The system messagemay be an e-mail message. A customer receives an e-mail message, and thee-mail message contains a link to the system gateway such as describedin FIG. 4 of the drawings. The difference here is that the link is inthe e-mail message and not at the merchant site, but otherwise operationis similar. Details of the person who is to be paid may be exacted fromthe e-mail or a system database.

The person who is to be paid may be anybody. It could a utilityprovider, for example, sending out a utility bill. It may be anotherperson merely requiring payment into their account from the payer.

Modifications and variations as would be apparent to a skilled addresseeare deemed to be within the scope of the present invention.

1. An online payment process comprising connecting a customer computingsystem to a computing system controlled by a financial institutionresponsive to a purchase selection received via a merchant website,making accessible to the customer computing system an account interfacethat facilitates selection of a customer controlled account from aplurality of customer controlled accounts, the selection designating,for payment of a purchase fee defined by the merchant website, acustomer controlled account maintained by the financial institution,receiving payment confirmation from the financial institution controlledcomputing system following transfer of the purchase fee from thefinancial institution directly to an account specified by the merchantwebsite, and transferring the payment confirmation to the merchantwebsite without intervention from the customer computing system.
 2. Theprocess of claim 1 comprising transferring payment data, including apurchase fee and a merchant account for payment of the purchase fee,from the merchant website to the financial institution controlledcomputing system.
 3. The process of claim 1 comprising receiving aninstitution selection from the customer computing system that designatesa financial institution for payment of the purchase fee.
 4. The processof claim 1 comprising transferring a security device directly from thecustomer computing system to a financial institution application hostedby the financial institution controlled computing system to authenticatethe customer computing system.
 5. The process of claim 4 comprisinginterfacing the customer computing system with the account interface viathe financial institution application responsive to authentication ofthe customer computing system via the security device.
 6. The process ofclaim 1 comprising facilitating authorisation of payment, by thecustomer computing system, from the selected customer controlled accountto an account specified by the merchant website, the paymentauthorisation authorising the financial institution to transfer thepurchase fee directly from the selected customer controlled account tothe account specified by the merchant website.
 7. The process of claim 1comprising transferring payment authorisation from the customercomputing system to the financial institution controlled computingsystem and payment confirmation from the financial institutioncontrolled computing system to the merchant website in real-time.
 8. Theprocess of claim 1 comprising making accessible to the customercomputing system, for each of the customer banking accounts accessiblevia the account interface, an account balance that represents the fundsavailable from the respective account.
 9. The process of claim 1comprising initiating a dedicated financial institution active agentgateway that connects the customer computing system directly to anonline banking interface provided by the financial institutioncontrolled computing system responsive to a financial institutionselection from the customer computing system.
 10. An online paymentsystem comprising a transaction computing system having a processor andmemory containing instructions that are executable by the processor toconnect a customer computing system to a computing system controlled bya financial institution, the instructions being executable responsive toa customer purchase selection received via a merchant website to causethe transaction computing system to make accessible, to the customercomputing system, an account interface that facilitates selection of acustomer controlled account from a plurality of customer controlledaccounts, the selection designating, for payment of a purchase feedefined by the merchant website, a customer controlled accountmaintained by the financial institution, the transaction computingsystem being configured to receive payment confirmation from thefinancial institution controlled computing system following transfer ofthe purchase fee from the financial institution directly to an accountspecified by the merchant website, and transfer the payment confirmationto the merchant website without intervention from the customer computingsystem.
 11. The system of claim 10 wherein the instructions areexecutable to cause the transaction computing system to transfer paymentdata, including a purchase fee and a merchant account for payment of thepurchase fee, from the merchant website to the financial institutioncontrolled computing system.
 12. The system of claim 10 wherein theinstructions are executable to cause the transaction computing system toreceive an institution selection from the customer computing system thatdesignates a financial institution for payment of the purchase fee. 13.The system of claim 10 wherein the instructions are executable to causethe transaction computing system to transfer a security device directlyfrom the customer computing system to a financial institutionapplication hosted by the financial institution controlled computingsystem to authenticate the customer computing system.
 14. The system ofclaim 13 wherein the instructions are executable to cause thetransaction computing system to interface the customer computing systemwith the account interface via the financial institution applicationresponsive to authentication of the customer computing system via thesecurity device.
 15. The system of claim 10 wherein the instructions areexecutable to cause the transaction computing system to facilitateauthorisation of payment, by the customer computing system, from theselected customer controlled account to an account specified by themerchant website, the payment authorisation authorising the financialinstitution to transfer the purchase fee directly from the selectedcustomer controlled account to the account specified by the merchantwebsite.
 16. The system of claim 10 wherein the instructions areexecutable to cause the transaction computing system to transfer paymentauthorisation from the customer computing system to the financialinstitution controlled computing system and payment confirmation fromthe financial institution controlled computing system to the merchantwebsite in real-time.
 17. The system of claim 10 wherein theinstructions are executable to cause the transaction computing system tomake accessible to the customer computing system, for each of thecustomer banking accounts accessible via the account interface, anaccount balance that represents the funds available from the respectiveaccount.
 18. The system of claim 10 wherein the instructions areexecutable to cause the transaction computing system to initiate adedicated financial institution active agent gateway that connects thecustomer computing system directly to an online banking interfaceprovided by the financial institution controlled computing systemresponsive to a financial institution selection from the customercomputing system.
 19. An online payment process comprising connecting acustomer computing system to a computing system controlled by afinancial institution, responsive to a purchase selection received via amerchant website, making accessible to the customer computing system anaccount interface that facilitates selection of a customer controlledaccount maintained by the financial institution, the account interfacefacilitating payment of a purchase fee from the financial institutiondirectly to an account specified by the merchant website.
 20. Theprocess of claim 19 comprising initiating a dedicated financialinstitution active agent gateway that connects the customer computingsystem directly to an online banking interface provided by the financialinstitution controlled computing system following a financialinstitution selection from the customer computing system.